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© Each component (101) of a plurality of interact- 
ing system components is associated with a version 
identifier (102). The version identifier (102) is stored 
in a location accessible by the other components. 
Each component independently reads the version 
identifier of every other component with which it 
must interact, and compares this value to an inter- 
nally stored compatibility record (103) to determine 
whether the other component satisfies requirements 
for compatibility with the verifying component. Any 
component which detects an incompatibility signals 
an error to the system. In the preferred embodiment, 
the components are software modules, and the ver- 
sion identifier and compatibility record contain in- 
teger values. The compatibility record value repre- 
sents the minimum level required of the module 
being verified for compatibility with the verifying 
module. Compatibility verification is accomplished 
by comparing the actual level of the module being 
verified with the minimum level in the compatibility 
record. If the actual level is equal to or greater than 
the minimum level, the module being verified satis- 
fies compatibility requirements. 
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The present invention relates to data process- 
ing component usage, and in particular to verifying 
that two or more interacting components of a digital 
data system are compatible with each other. 

A modern computer system typically com- 
prises a variety of different interconnected proces- 
sors, each executing its own software. A single 
central processing unit (CPU) is typically the basic 
workhorse of the computer, but other processors 
control disk storage devices, printers, terminals, 
communications with other computers, etc. Even 
more remote and primitive processors may control 
other functions, such as monitoring sensors, input 
keypads, etc. In addition, multiple computer sys- 
tems may be connected to a network, whereby 
they may communicate with each other. 

In such a system, it is common for multiple 
system components to interact with each other. For 
exampl , interacting software modules may be run- 
ning in separate processors or in a single proces- 
sor. Processors which control peripheral functions, 
such as disk storage controllers, must be able to 
transmit data to and from the system CPU using 
som defined protocol. Therefore the software run- 
ning in the peripheral processor must be compati- 
ble with the operating system software of the main 
system. Similarly, multiple software modules may 
be sharing the CPU and certain system resources. 
These modules may interact, for example, by shar- 
ing memory, and must be compatible in the way 
they acc ss and alter the shared data. 

System components, and particularly software 
modules, are subject to frequent revision, either to 
correct known errors in the component or to en- 
hanc its function. As a result of these frequent 
revisions, many versions of a component may ex- 
ist, each with slightly different capabilities. Some 
versions of a component may therefore be in- 
compatible with some versions of an interacting 
module. For example, if software modules A and B 
share a data structure, the addition of a new func- 
tion to module A may require a new field in the 
data structure, and consequently require a new 
version of module B to support this new field, 

Wh re multiple software modules are licensed 
from a single source and as a single package, the 
software developers can solve the problem of in- 
compatible revision levels by guaranteeing that all 
modules shipped as part of the package are com- 
patible with each other. A number of techniques 
exist in the art for tracking changes to software in 
the development environm nt and testing interact- 
ing modules before shipment to the customer to 
verify compatibility. However, where one module 
must interact with another from a different source, 
or that may hav be n acquired from the same 
source at a different time, the problem becomes 
more complex. 



One approach to the problem is to allow the 
modules to execute and let standard system error 
recovery procedures detect incompatibility. While 
this may work in some cases, there is no guarantee 

5 that the system error recovery procedures will al- 
ways detect incompatibility. For example, the in- 
compatibility may be one which will corrupt data 
without generating an error condition. Another ap- 
proach is to require that all modules be at the 

to same level. While this guarantees module compati- 
bility, it is unduly restrictive. Some modules may 
be compatible with each other even though not at 
the same level. This problem is particularly acute 
in the case of components which are not easily 

is replaced not easily replaced, as for example, when 
software for a peripheral controller is stored in a 
read-only memory- There exists a need for a gen- 
eral method of verifying compatibility of system 
components, which will not prevent compatible 

20 components of differing version levels from inter- 
acting. 

ft is therefore an object of the present invention 
to provide an enhanced method and apparatus for 
verifying compatibility of a plurality of interacting 

25 system components. 

ft is therefore an object of the present invention 
to provide an enhanced method and apparatus for 
verifying compatibility of a plurality of interacting 
software modules. 

30 Another object of this invention to provide a 

more reliable method and apparatus for detecting 
component incompatibility. 

Another object of this invention is to reduce the 
instances of reported incompatibility among inter- 

35 acting components which are in fact compatible. 

Another object of this invention is to reduce the 
need for replacing interacting components which 
are in fact compatible. 

Another object of this invention is to reduce the 

40 cost of operating a computer system with multiple 
interacting system components. 

Each component of a plurality of interacting 
system components is associated with a version 
identifier, which in the preferred embodiment is an 

45 integer value. The version identifier is stored in a 
location accessible by the other system compo- 
nents. Each component independently reads the 
version identifier of every other component with 
which it must interact, and compares this value to 

so an internally stored compatibility record to deter- 
mine whether the other component satisfies re- 
quirements for compatibility with the verifying com- 
ponent. Any component which detects an incom- 
patibility signals an error to th system. It is possi- 

55 ble under this arrangem nt for component A to 
satisfy compatibility criteria required by component 
B, but not vice v rsa. 

In the preferred embodiment, the components 
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are software modules. It is assumed that a software 
module at any arbitrary level will satisfy all com- 
patibility requirements that ar satisfied by each 
lower level of that same module. The compatibility 
record contains an integer representing the mini- 
mum level required of the module being verified for 
compatibility with the verifying module. Compatibil- 
ity verification is accomplished by comparing the 
actual I vel of the module being verified with the 
minimum level in the compatibility record. If the 
actual I vel is equal to or greater than the minimum 
lev I, the module being verified satisfies compati- 
bility requirements. 

Fig. 1 shows a typical system component in its 
environment according to the preferred embodi- 
m ntof this invention; 

Fig. 2 is a block diagram of the steps required 
in each component to verify compatibility with 
interacting components, according to the pre- 
ferred embodiment; 

Fig. 3 shows an example of a computer system 

using this invention. 
Figure 1 shows a typical system component 
101 in its environment according to the preferred 
embodiment of the present invention. In this pre- 
ferred embodiment, the component is a software 
module 101 comprising a block of machine instruc- 
tions and data stored in a memory 110. Module 
101 xecutes in a programmable processor 111 
coupl d to the memory. Module 101 interacts with 
one or more other software modules to perform 
some desired function. Module 101 contains ver- 
sion identifier 102, which in the preferred embodi- 
ment is an integer value. In the preferred embodi- 
ment, the version identifier is stored in a pre- 
defined memory location in the module, from which 
it can be read by other modules. Module 101 also 
contains compatibility check routine 103, which 
comprises component version table 104 and a se- 
ries of instructions to access the version identifiers 
of int racting modules and compare these to val- 
ues in table 104. Component version table contains 
one or more entries 105, each entry corresponding 
to a software module with which module 101 must 
interact. Each entry 105 comprises component 
class field 106 which identifies the interacting soft- 
ware module, and compatible version field 107 
identifying the compatible versions of the interact- 
ing module. In the preferred embodiment, compati- 
ble version field 107 is an integer representing the 
minimum version level of the interacting module 
which satisfies requirements for compatibility with 
software module 101. 

In the preferred embodiment, compatibility 
check routine 103 directly accesses the version 
identifier in each interacting module by accessing a 
memory location which is a fixed offset from the 
beginning of the interacting module. However, any 
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number of alternative methods could be mployed. 
For example, in one alternate embodiment, a sepa- 
rat softwar module, callable by each of the Inter- 
acting modules, could contain a fetch version func- 

5 tion which accesses the location of the version 
identifiers. A software module would access the 
version identifier of another software module by 
issuing a call to the fetch version function, passing 
it the component name of the software module for 

10 which the version identifier is desired. In another 
alternative embodiment, an operating system reads 
all module version identifiers and creates a table of 
such identifiers in a location accessible to all mod- 
ules. In another alternative embodiment, the mod- 

15 ule performing compatibility checking interrogates 
the interacting module for its version identifier via a 
pre-defined interface. The present invention only 
requires that each module in a set of interacting 
modules have means for accessing the version 

20 identifiers of the other modules in the set. 

Figure 2 shows the steps required in each 
module of a set of interacting modules to verify 
compatibility of the set. In accordance with this 
invention, each module of the set must indepen- 

25 dently verify that each other module with which it 
interacts satisfies minimum requirements for com- 
patibility with the module. Each module of the 
interacting set first accesses the version identifier 
of an interacting component (step 201), and ac- 

30 cesses the minimum version level required for 
compatibility with the component from its compo- 
nent version table 104 (step 202). If the actual level 
represented by the version identifier is less than 
the minimum level from the table (step 203), the 

35 interacting component being verified is added to an 
error list (step 204). If there are more interacting 
components to check, the process repeats (step 
205), until all interacting components have been 
checked. When all components . have been 

40 checked, if any components are in the error list 
(not compatible with the component performing 
compatibility checking) (step 206), an error con- 
dition is signalled (step 207). The response of the 
system to such an error condition would be depen- 

45 dent on the application, but it would generally 
mean that the modules would not be permitted to 
execute, because results may be unpredictable. 

In the preferred embodiment, it is assumed 
that a software module at any arbitrary level will 

50 include the capabilities and functions of each lower 
level of that same module that are required for 
compatibility with other modules. Thus, for pur- 
poses of compatibility, a higher level of a module 
being verified will always satisfy minimum require- 

55 ments for compatibility with the verifying module if 
any lower level of th module being v rified satis- 
fies such compatibility requirements. Accordingly, it 
is pref rred that the version identifier be an integer, 

3 
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permanent read-only memory coupled to the pro- 
cessor, while the second is stored in an electrically 
erasable memory coupled to the processor. From 
time to time the computer's operating system will 
download a new version of the second module, but 
it is unable to alter the first. As a result of a new 
version of the operating system, it is possible that 
the first module will no longer satisfy requirements 
for compatibility with the second. In addition, it is 
possible that a pluggable device will be replaced or 
added without an upgrade to the operating system, 
and consequently that the second module will no 
longer satisfy requirements for compatibility with 
the first. In this simplified embodiment, it is not 
nec ssary to maintain a component version table 
with ntries for different modules, because only 
on other module need be checked. Therefore the 
minimum version level required to meet compatibil- 
ity requirements is hard-coded into the software 
module as a constant value, eliminating the need 
for instructions that look up the value from a table. 
Each module compares the version level of the 
other module with this hard-coded constant to ver- 
ify compatibility. If an incompatibility is detected, 
an appropriate message is sent to the operating 
system. The operating system may be able to cure 
the problem by downloading a different version of 
the second module; if not, appropriate action is 
tak n to inhibit interaction between the two soft- 
ware modules. 

Although in the preferred embodiment, the sys- 
tem components being verified for compatibility are 
software modules, in an alternative embodiment 
this invention can be used to verify compatibility of 
hardware components or components that are 
combinations of hardware and software. For exam- 
ple, el ctronic circuit cards in a computer system 
ar also subject to frequent revision for the same 
reasons that software modules are. In accordance 
with this alternative embodiment, a circuit card 
comprises a programmable processor executing a 
software module. A permanent version identifier is 
associated with the combination of the card and its 
software. The card verifies compatibility with inter- 
acting circuit cards as described above for software 
modules. 

Although a specific embodiment of the inven- 
tion has been disclosed along with certain alter- 
natives, it will be recognized by those skilled in the 
art that additional variations in form and detail may 
be made within the scope of the following claims. 

Claims 

1. A method for v rifying that a plurality of sys- 
tem components xecuting on a computer sys- 
t m are compatible with each other, wherein a 
component version is associated with ach of 



said plurality of components, and wherein each 
of said components is associated with a com- 
ponent version identifier identifying the compo- 
nent version of said component, said method 
5 being characterized in that it comprises the 

steps of: 

- obtaining the component version iden- 
tifier (102) associated with a first (101) of 
said plurality of components; 

70 - determining whether the component ver- 

sion identified by said component ver- 
sion identifier (102) associated with said 
first module satisfies requirements for 
compatibility with a second of said plural- 

15 ity of components; 

- obtaining the component version iden- 
tifier associated with said second of said 
plurality of components; and 

- determining whether the component ver- 
so sion identified by said component ver- 
sion identifier associated with said sec- 
ond component satisfies requirements for 
compatibility with said first (101) of said 
plurality of components. 

25 

2. The method for verifying compatibility accord- 
ing to claim 1 , characterized in that each com- 
ponent version identifier (102) associated with 
a component (101) is stored in a fixed exter- 

30 nally accessible location within the respective 

component (101). 

3. The method for verifying compatibility accord- 
ing to claim 1, characterized in that each said 

35 component (101) is a software module. 

4. The method for verifying compatibility accord- 
ing to claim 3, characterized in that said step 
of determining whether the component version 

40 identified by said component version identifier 

(102) associated with said first component 
(101) satisfies requirements for compatibility 
with a second component comprises the steps 
of: (a) accessing compatible component ver- 

45 sion identifier information in said second com- 

ponent, and (b) comparing said component 
version identifier (102) associated with said 
first component (101) with said compatible 
component version identifier information in said 

so second component; and said step of determin- 

ing whether the component version identified 
by said component version identifier associ- 
ated with said s cond component satisfies re- 
quirements for compatibility with said first 

55 component (101) comprises the steps of: (a) 

accessing compatible component version iden- 
tifi r information in said first component (101), 
and (b) comparing said component version 
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identifier associated with said second compo- 
nent with said compatible component version 
identifier information in said first component 
(101). 

5 

5- The method for verifying compatibility accord- 
ing to claim 4, characterized in that each com- 
ponent version identifier associated with a 
component is stored in a fixed externally ac- 
cessible location within the respective compo- io 
nent. 

6- The method for verifying compatibility of claim 
4, characterized in that said compatible com- 

pon nt version identifier information in said 75 
first and second components comprises in 
each of said components a table (104) of com- 
patible component version identifier values. 

7. The method for verifying compatibility of claim 20 
4, characterized in that said component version 
identifier associated with each of said first and 
second components comprises an ordered val- 
ue representing a component version level of 
the respective component; 2s 
said compatible component version identifier 
information contained in each of said first and 
second components comprises an ordered val- 
ue representing a minimum compatible com- 
ponent version level; said step of comparing 30 
said component version identifier associated 
with said first component (101) with said com- 
patible version identifier information contained 
in said second component comprises compar- 
ing said ordered value representing the com- 35 
ponent version level of said first component 
(101) with said ordered value representing a 
minimum compatible component version level 
in said second component and determining 
that said first component satisfies requirements 40 
for compatibility with said second component if 
said ordered value representing the component 
version level of said first component is greater 
than or equal to said ordered value represent- 
ing a minimum compatible component version 45 
level in said second component; and said step 
of comparing said component version identifier 
associated with said second component with 
said compatible version identifier (102) infor- 
mation contained in said first component (101) so 
comprises comparing said ordered value re- 
presenting the compon nt version level of said 
s cond component with said ordered value re- 
presenting a minimum compatible component 
v rsion level in said first component and deter- 55 
mining that said second component satisfies 
requir ments for compatibility with said first 
component if said ordered value representing 



the component version level of said second 
component is greater than or equal to said 
ordered value representing a minimum com- 
patible component version level in said first 
component. 

8. A first system component of a plurality of 
interacting components of a computer system, 
wherein a component version is associated 
with each of said plurality of interacting com- 
ponents, said first system component being 
characterized by : 

- identifier fetching means for obtaining the 
component version identifier associated 
with a second component of said plural- 
ity of interacting components; 

- means for accessing compatible compo- 
nent version identifier information for said 
first component (1 01 ); 

- comparing means for comparing said 
component version identifier obtained by 
said identifier fetching means with said 
compatible component version identifier 
information to determine whether the 
component version identified by said 
component version identifier satisfies re- 
quirements for compatibility with said 
first component (101). 

9. The first system component according to claim 
8, characterized in that said component version 
identifier (102) associated with said first com- 
ponent (101) is stored in a fixed location within 
said first component accessible to means for 
accessing said component version identifier 
contained in said second component. 

10. The first system component according to claim 
8, characterized in that said component is a 
software module. 

11. The first system component according to claim 
8, characterized in that each said component 
version identifier associated with a component 
comprises an ordered value representing a 
component version level of the respective 
module; said compatible component version 
identifier information associated with said first 
component (101) comprises an ordered value 
representing a minimum compatible compo- 
nent version level; and said comparing means 
compares said ordered value representing the 
component version level with said ordered val- 
ue repr sen ting a minimum compatible com- 
ponent v rsion I vel in said first component 
(101) and determines that said component ver- 
sion satisfies requirements for compatibility 
with said first component if said ordered valu 
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representing the component version level is 
greater than or equal to said ordered value 
representing a minimum compatible compo- 
nent version level in said first component. 

12. The first system component according to claim 
11, characterized in that said component ver- 
sion identifier (102) associated with said first 
component (101) is stored in a fixed location 
within said first component accessible to 
means for accessing said component version 
identifier 

contained in said second component. 

13. The first system component according to claim 
11, characterized in that said component is a 
software module. 

14. A computer system comprising: 

- at least one programmable processor 

OH); 

- a plurality of interacting system compo- 
nents (101). 

wherein a respective component version 
identifier (102) is associated with each of 
said plurality of interacting components; 

- means for obtaining the component ver- 
sion identifier (102) associated with a first 
(101) of said plurality of components; 

- means for determining whether the com- 
ponent version identified by said compo- 
nent version identifier (102) associated 
with said first module satisfies require- 
ments for compatibility with a second of 
said plurality of components; 

- means for obtaining the component ver- 
sion identifier associated with said sec- 
ond of said plurality of components; and 

- means for determining whether the com- 
ponent version identified by said compo- 
nent version identifier associated with 
said second component satisfies require- 
ments for compatibility with said first of 
said plurality of components. 

15. The computer system according to claim 14, 
characterized in that each component version 
identifier associated with a component is 
stored in a fixed externally accessible location 
within the respective component 

16. The computer system according to claim 14, 
characterized in that each said interacting sys- 
tem component is a software modul . 

17. The computer system according to claim 16, 
characterized in that : said means for deter- 
mining whether the component version iden- 



tified by said component version identifier as- 
sociated with said first component (101) satis- 
fies requir ments for compatibility with a sec- 
ond component comprises: (a) means for ac- 

5 cessing compatible component version iden- 

tifier information in said second component, 
and (b) means for comparing said component 
version identifier associated with said first 
component (101) with said compatible compo- 

70 nent version identifier information in said sec- 

ond component; and said means for determin- 
ing whether the component version identified 
by said component version identifier associ- 
ated with said second component satisfies re- 

76 quirements for compatibility with said first 

component comprises: (a) means for acces- 
sing compatible component version identifier 
information in said first component, and (b) 
means for comparing said component version 

20 identifier associated with said second compo- 

nent with said compatible component version 
identifier information in said first component. 

18. The computer system according to claim 17, 
25 characterized in that each component version 

identifier associated with a component is 
stored in a fixed externally accessible location 
within the respective component. 

30 19. The computer system according to claim 17, 
characterized in that said component version 
identifier associated with each of said first and 
second components comprises an ordered val- 
ue representing a component version level of 

35 the respective component; said compatible 

component version identifier information con- 
tained in each of said first and second compo- 
nents comprises an ordered value representing 
a minimum compatible component version lev- 

40 el; said means for comparing said component 

version identifier associated with said first 
component with said compatible version iden- 
tifier information contained in said second 
component compares said ordered value re- 

45 presenting the component version level of said 

first component (101) with said ordered value 
representing a minimum compatible compo- 
nent version level in said second component 
and determines that said first component 

so (101) satisfies requirements for compatibility 

with said second component if said ordered 
value representing the component version level 
of said first component is greater than or equal 
to said ordered value representing a minimum 

55 compatible component version level in said 

second component; and said means for com- 
paring said component v rsion id ntift r asso- 
ciated with said second component with said 
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compatible version identifier (102) information 
contained in said first component compares 
said ordered value representing the component 
version level of said second component with 
said ordered value representing a minimum 5 
compatible component version level in said 
first component and determines that said sec- 
ond component satisfies requirements for com- 
patibility with said first component (1 01 ) if said 
ordered value representing the component ver- io 
sion level of said second component is greater 
than or equal to said ordered value represent- 
ing a minimum compatible component version 
level in said first component. 
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^) Each component (101) of a plurality of interact- 
ing system components is associated with a version 
identifier (102). The version identifier (102) is stored 
in a location accessible by the other components. 
Each component independently reads the version 
identifier of every other component with which it 
must interact, and compares this value to an inter- 
nally stored compatibility record (103) to determine 
whether the other component satisfies requirements 
for compatibility with the verifying component. Any 
component which detects an incompatibility signals 
an error to the system. In the preferred embodiment, 
the components are software modules, and the ver- 
sion identifier and compatibility record contain in- 
teger values. The compatibility record value repre- 
sents the minimum level required of the module 
being verified for compatibility with the verifying 
module. Compatibility verification is accomplished 
by comparing the actual level of the module being 
verified with the minimum level in the compatibility 
record. If the actual level is qua! to or greater than 
the minimum level, the module being verified satis- 
fies compatibility requirements. 
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